home *** CD-ROM | disk | FTP | other *** search
/ BCI NET 2 / BCI NET 2.iso / archives / grafix / boards / a2410src.lha / Public / Readme < prev    next >
Encoding:
Text File  |  1995-02-19  |  4.4 KB  |  105 lines
  1. This distribution is a try to run the WB on the A2410 U.Lowell
  2. TIGA board, sold by Commodore. 
  3. It is not ready. Well it is really hard to rewrite the graphics
  4. library so I decided to make my work public available.
  5. Public extensions or further development is welcome. 
  6. The big BUT is : It MUST be public available !
  7. This makes sure the potential of a lot good shareware
  8. programmers could help this library become a widely available
  9. standart.
  10.  
  11. Some thoughts to the mechanism the library works.
  12.  
  13. By now it is just a experimental library. It should not be
  14. used as an Intuition Emulation in this form. What I would like
  15. to have are Class Libraries for each GfxBoard. Every Gfxfunction
  16. is a sub set of this Class so new function could be overloaded
  17. from a new Driver and Standard functions can also be used.
  18. Well, this is how EGS does things ! I like the way they do it.
  19. EGS is an alien GUI and it is not based on C, which makes
  20. the implementation real hard in C (Well, I am writing an EGS
  21. driver by now, so I know what I'm talking about !).
  22.  
  23. This would make sure we get an RTG driver some times an
  24. it is a modern conception because it uses basic objects
  25. as the main layer. Also it would be easy to write new drivers
  26. for any other board.
  27.  
  28. The current library does nothing than just patching around and replacing
  29. some gfx.library functions. I do not think this is what a modern
  30. graphics driver should do. But the main function code can be used
  31. as the basic graphics object code (s. above).
  32.  
  33. The advantage of objects shows the following illustration :
  34.  
  35.  +-------------------------------------------------------+
  36.  | virtual area (invisible, e.g. superbitmap)            |
  37.  | (clipping area)                                       |
  38.  |          +-----------------------+                    |
  39.  |          | visible window        |                    |
  40.  |          |                       |                    |
  41.  |          |            \          |                    |
  42.  |          | normal line \         |                    |
  43.  |          +-----------------------+                    |
  44.  |                          \                            |
  45.  |                           \ clipped line              |
  46.  +-------------------------------------------------------+
  47.  
  48. The visible Window would require hardware dependent drawing functions,
  49. the invisible line could be a standard function (bitmap). Normaly a
  50. friend of the visible function. This makes converting bitmaps unnecessary
  51. and would speed things up when updating hidden areas.
  52. (That's the problem of most Intuition Emulations right now. If the 
  53. hidden area is a plane map, it has to be converted to chunky on refresh !).
  54.  
  55. To implement this in a RTG.libray - some sort of an OS replacement/enhancement
  56. of the graphics library - would make this problem obsolent.
  57.  
  58. In the above example it would be like
  59.  
  60.     if (ClipLine(rect) == visible)
  61.         DrawLine(BOARD0)
  62.     else
  63.         DrawLine(STANDARD)
  64.  
  65. ....
  66.  
  67. Well, I know this is a lot of work. Most parts of the graphics.libray has to be
  68. rewritten - and it must be OS compatible. But it is the only solution to keep
  69. the graphics engine up to date !
  70.  
  71. So what has to be done first is to implement a mechanism to decide which class
  72. to draw. If this does work, the specific code has to be written for different
  73. gfx boards.
  74.  
  75. Well, I am not very used to objective programming of the Amiga (except MUI :-)
  76. so I would think it should be a sort of BOOPSI classes and/or C++ classes !
  77.  
  78. Maybe if I get a C++ compiler sometimes I will try if it would make sence to
  79. write C++ classes. Also I should take a look on BOOPSI classes and check out how
  80. I could implement them into the current gfx.library code ...
  81.  
  82. On the other side the patches will stay there. It is not possible to hook these
  83. new functions into the OS so they have to be patched ! Though I think it does not
  84. make any difference. Patching IS a OS friendly way to hook new functions into the
  85. system !
  86.  
  87. If somebody is interessted - go ahead.
  88. I do not know how much time I have to coordinate such a (BIG !) project...but I
  89. think there are a lot "wise" guys (and girls ?) out there who could make this
  90. ideas a future standard. And it will be public available !
  91. See the source files for more information !
  92.  
  93. Well, if somebody is interested in finishing the A2410 driver .. let me know.
  94. (And don't blame me on the code ! =:-)
  95.  
  96. you can reach me at
  97.  
  98. Juergen Schober
  99. Muchargasse 35/1/4
  100. A-8010 Graz
  101. AUSTRIA
  102. ----
  103. e-mail : point@sbox.tu-graz.ac.at
  104.          (or f9031304@mbox.tu-graz.ac.at)
  105.